今天要討論的是當我們對API Server下Request時的權限控管，首先我們要談的是Kubernetes的API～

API Groups

Kubernetes的API主要分為兩大類：

• api：Core group，它為Kubernetes的基本功能，像是Pods。
  • route：/api/v1
  • apiVersion：v1
• apis：Named group，像是Deployment之類較為進階的功能。
  • route：/apis/$GROUP_NAME/$VERSION
  • apiVersion：$GROUP_NAME/$VERSION

其他的API Groups可以在官網中找到，或是直接問我們的API Server～

# 看全部的API Groups
curl [http://localhost:6443](http://localhost:6443) -k

# 只看Named Groups
curl h[ttp://localhost:6443](http://localhost:6443)/apis -k | grep "name"

如何對API Server下Request？

如果我們直接Call API Server，那麼高機率會出現Failure。這是因為我們沒有權限可以做這件事，那要如何做到呢？只需要加上授權，讓集群的安全機制知道我們是有受過認證的就行了～

curl [http://localhost:6443](http://localhost:6443) -k  --key admin.key --cert admin.crt --cacert ca.crt

我們還可以透過kubectl來代替我們做到這件事～

kubectl proxy

這行指令的作用是將本地的8001 Port，作為API Server的代理，所以當kubectl proxy正在運作時，我們就可以直接透過8001 Port來對API Server下指令而不需要授權了～

curl [http://localhost:](http://localhost:6443)8001 -k

另外要注意的是，這邊的kubectl proxy和kube proxy是不同的喔～

Authorization Mechanisms

我們在使用Kubernetes應該會有很多種角色，像是管理人員、開發者、Bots，而他們彼此之間所需要的功能與權限也不是一樣的，為了安全性考量，控管他們的權限就是非常重要的。

Kubernetes的權限控管機制主要可以分為四大類：

• Node：我們前面提過kubelet是管理Node的主要元件，而這個授權機制是應用在kubelet所發出的API request。
• ABAC (Attribute-based access control)：我們對這個使用者設定了他可以對哪些Object做什麼事，每個使用者都要分開設定。
• RBAC (Role-based access control)：我們建立了一個Role，然後賦予他可以對什麼Object可以做什麼事的權限，再將數個使用者綁定到這個Role上。
• Webhook：將權限控管機制外包出去，當某個使用者要對集群做某些事情的時候，就會透過外部服務來確認權限。

除了這四種機制以外，還有另外兩種模式：

• AlwaysAllow：不檢查權限，總是通過。
• AlwaysDeny：全部都拒絕。

要設定這些權限控管模式可以在API Server中使用這個參數：

--authorization-mode=RBAC

# 也可以同時設置多個
--authorization-mode=Node,RBAC,Webhook

若是同時設置多個模式，那系統在會先測試某一個，若是發生錯誤，再測試下一個，直到成功或是全都失敗才結束。

明天會討論RBAC～

參考資料

API 概述

鉴权概述